home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
MacWorld 1996 July
/
Macworld (1996-07).dmg
/
Shareware Picks
/
MacTCP Monitor
/
READ ME
< prev
Wrap
Text File
|
1995-10-17
|
26KB
|
567 lines
MacTCP Monitor
by Chris Johnson
©1994 The University of Texas System Office of Telecommunication Services
Welcome to the early days of testing for MacTCP Monitor, and an experimental
Simple Internet Version Control (SIVC - pronounced "civic") server.
MacTCP Monitor is a simple (in concept, anyway) utility for displaying your
Mac's TCP activity. It continuously graphs the number of bytes sent/received
by MacTCP in any given second. This can be handy for keeping an eye on the
activity of servers running in the background of your Mac, or for gauging
at-a-glance the throughput of that TCP code you've been working on lately.
MacTCP Monitor requires at least System 7, Apple's Thread Manager extension
(which is built into System 7.5, BTW), Color QuickDraw, and, of course,
MacTCP. :-) Note that some optional parts of MacTCP Monitor only work if
Peter N. Lewis' "Anarchie" and "MacTCP Watcher" utilities are present on your
machine.
The TCP Data Transfer Graph window can be resized from any edge/corner (when
the mouse is near enough to an edge/corner, the cursor will change
accordingly to show you what's going on). The width of the label area on the
left side of the window can be changed by dragging its dividing line. The
window can be dragged from any point in the window that isn't an edge/corner
or the aforementioned dividing line (the cursor will change to a hand shape).
And, of course, be sure to check-out the dialogs accessible via the
"Preferences" items in the File menu to see how you can customize MacTCP
Monitor's behavior.
If you have comments, bug reports, etc. send them to "chrisj@mail.utexas.edu".
So What's That SIVC Thing You Mentioned?
----------------------------------------
SIVC (a client of which is built into MacTCP Monitor) is a system for doing
two things:
1. Determining the size of a product's user base on the Internet. This is
really useful when you're trying to justify working on a product to
yourself or your boss. Just waving your arms and asserting that there
*must* be lots of people using your product because you've received
a bunch of email messages about it isn't really very convincing. SIVC
provides the developer with real numbers that are generally accurate
and continuously updated.
2. In keeping with the idea that this exchange of information shouldn't
benefit only the developer, a SIVC server returns to the client current
version information for the product, including the exact location from
which the current version(s) can be downloaded. This allows the
application to notify its users when new versions are released, and
even makes it easy for the application to download new versions of
itself for the user.
What about privacy? SIVC shouldn't represent a threat to most people's privacy.
The only information the SIVC client in this program sends to the server is:
(1) the name of this program, and (2) the version of this program. The server
will also log the IP number from which this information was received. So, the
server doesn't know your name, email address, etc. It just logs the fact that
someone at IP number X is running version Y of this program. Hopefully this
won't represent a problem for anyone.
If you do feel that SIVC represents a threat to your privacy, you can disable
all SIVC features in MacTCP Monitor from the "Internet Version Control"
preferences dialog found in the "File" menu. Personally, I'd very much prefer
that people leave SIVC *enabled*, however. Without it, I don't know if anyone
is using the product.
Note to developers: if you're interested in using SIVC in one of your
products, you can now get all the necessary information, software, etc. from:
http://www.ots.utexas.edu/sivc/index.html
Changes in 1.0d34
-----------------
* Corrected a possible problem in the URL accessing code that might have
prevented users who haven't installed Internet Config from being able to
download new versions of MacTCP Monitor from the SIVC dialog. Everyone
*should* have Internet Config installed on their Macs, but I know that's
too much to hope for in practice. Sigh.
If you want a copy of Internet Config, it's available from most of your
favorite Mac archive sites, or, if all else fails, from:
ftp://redback.cs.uwa.edu.au/Others/PeterLewis
* Improved the reporting of errors to users when URLs can't be accessed for
some reason.
* Minor cosmetic fix in the Internet Version Control preferences dialog.
Changes in 1.0d33
-----------------
* Added support for a 30 second running average dot in the TCP Data Transfer
Graph. By default it's drawn in cyan, and it indicates the average amount
of data read & written in the previous 30 seconds (inclusive). Strictly
speaking, this feature isn't limited to 30 seconds, but I haven't provided
the user interface to change this value yet. :-)
* Retries and duplicate packets are now graphed independently of the number
of bytes read or written in the TCP Data Transfer Graph. They are drawn in
yellow by default. In the past, these totals were simply graphed along with
the bytes read or written, as appropriate.
* Added code to the TCP statistics gathering system to cope with possibility
that the Time Manager task responsible for statistics gathering may not
always be activated at the required interval. For some reason, (presumably
interrupts are being disabled, but I'm not 100% sure) this appears to be a
problem when communicating by modem. I've verified that the code works, so
from now on, any spikes you see aren't my problem. :-)
* Eliminated problem that caused the data transfer graph's labels to be
drawn on a black background when used on monitor set to black & white.
* Added code to ensure the intended alignment of items in dialog boxes when
the system font differs from the one I used when laying-out the dialogs.
Users of user interface enhancements like Aaron will benefit.
* Changed default colors for the connection states cells. This change will
have no effect on you if you've already specified other colors for those
cells.
Changes in 1.0d32
-----------------
* Added a mode in which MacTCP Monitor will sit dormant until MacTCP is
opened by some other program. When 'Monitor is in the foreground, it will
display a dialog stating that it is waiting for MacTCP to be opened, and
offering you the option of opening MacTCP immediately. When 'Monitor is in
the background, the dialog is hidden. Whenever MacTCP is finally opened,
all the usual MacTCP Monitor windows will automatically appear at their
usual locations.
This feature is handy if you have a dial-up connection to the Internet,
since it gives you the option of placing MacTCP Monitor in your Startup
Items folder and letting it run all the time. Whenever you choose to
initiate a TCP/IP connection with the 'net, MacTCP Monitor's windows will
automatically appear.
In the past, MacTCP Monitor would have initiated a connection the moment
it was launched, making it highly annoying as a Startup Item (unless, of
course, you *wanted* to dial-up the 'net every single time you booted).
This "dormancy" feature can be enabled/disabled in the "General"
preferences dialog. It is enabled by default.
* Remembers whether or not the "TCP Data Transfer Graph" window was open the
last time the program was used, and behaves accordingly in successive
invocations. In the past, this window was always opened, regardless of
whether or not you'd closed it in a previous invocation.
* TCP Data Transfer Graph window can now be resized properly when located on
something other than the main monitor of multi-monitor systems.
* Replaced custom SIVC client code with a common implementation used in my
other products. Among other things, this means that the "Current Version
Info" dialog has a new and (IMHO) improved look.
* Removed bug that could cause the program to break into MacsBug if it
received a keystroke when no windows were open. (The bug was introduced in
1.0d31, which was not released.)
* Removed a bug that caused alerts to appear behind modal dialogs, instead
of in front of them.
* Verified thread stack allocations. All allocations should now be not only
sufficient, but should also include at least an extra 4K safety margin.
* Internet Config (version 1.1 or better) is now used when opening URLs,
so you don't have to put-up with my default client choices any more. If
you don't have Internet Config, you'll still be stuck with those default
client choices of mine. Note that in some upcoming version, Internet Config
will become a requirement rather than an option, so install it now, if you
haven't already. It's a good thing.
* Added a few lines of housekeeping code to delete some obsolete items from
the preferences file. They weren't hurting anything, but what the heck.
* The MacTCP Monitor preferences file now uses the standard preference file
icon.
Changes in 1.0d31
-----------------
* Not released. See changes in 1.0d32 for a cumulative list.
Changes in 1.0d30
-----------------
* Updated SIVC code to embrace latest improvements in protocol.
* Built app with latest versions of common code base (various minor tweaks
and bug fixes).
* Looked into making MacTCP Monitor work with Open Transport, but found
that it's going to take some serious work, so OT compatibility isn't in
this version.
Changes in 1.0d29
-----------------
* Finally found the true source of the disabled Apple menu bug some people
encountered. Thanks to Rick Watson for the use of his Mac while tracking
down this problem. Turns out one subroutine was surprised by menus with
more than 31 items in them, and bungled a test of the menu item states
when that was the case. As a result, people (like me) with relatively
uncrowded Apple menus didn't encounter this problem.
* While working on another program built on the same code base, found a
very obscure bug that could result in bogus values being passed as
pointers or handles to DisposPtr or DisposHandle, respectively. MacTCP
Monitor probably never exercised the afflicted piece of code in a way
that could cause the mistake to occur, but it was an annoying bug
elsewhere and I'm glad to be rid of it.
* Told the tables in the URL handling code that Eudora 3.0 will provide
support for "get URL" AppleEvents. Anyone out there who's testing it
should find that the "mailto:" URL in 'Monitor's About box will use that
new Eudora in preference to NewsWatcher, all things being equal (there
are cases in which it will use NewsWatcher anyway, but, you don't want
to know all the details).
It has been suggested that the URL code should, whenever possible, consult
Internet Config to determine the user's preferred client for any given
type of URL. In the future, it will. I've written Internet Config-aware
code before, so it should be straightforward. I'm just not gonna do it
right now. :-)
Changes in 1.0d28
-----------------
* Identified and fixed an old bug in the multithreaded application shell on
which MacTCP Monitor is based. The bug could cause pointers in one routine
to become invalid on occasion, which is certainly a bad thing. This fix
could take care of several infrequently reported bugs which I haven't been
able to reproduce in any of my own tests. It might even take care of the
disabled Apple menu bug a number of people have reported, but which I also
haven't been able to reproduce.
* An enhancement to the multithreaded application shell enables/disables the
Edit menu, and/or its underlying items, as appropriate while text is
manipulated in dialog text edit fields. A possible problem with clipboard
import/export in such situations should be history now, too.
Changes in 1.0d27
-----------------
* Finally acted on a suggestion by Chuck Shotten to change the keyword
delimiters in SIVC transactions from equal signs to colons. Making this
change required significant alterations to the SIVC server, and minor
changes to the client code in MacTCP Monitor. The changes to the SIVC
server were significant enough that it wasn't possible (given the time
constraints) to retain backward compatibility with the old SIVC code in
past versions of MacTCP Monitor. As a result, I'll run both the old and
new SIVC servers concurrently until the 'Monitor user base has more-or-
less universally upgraded to 1.0d27, thus eliminating any apparent loss
of service. As the two servers will be keeping separate user base totals,
those figures will suffer during this process, but it's better to make
the change-over now, rather than later.
This change also effects the format of the MacTCP Monitor Prefs file (the
same parsing code is used), but backward compatibility has been retained,
so users shouldn't be aware that anything has changed in this respect.
* Various minor improvements in the application shell on which 'Monitor is
built.
Changes in 1.0d26
-----------------
* Fixed a bug (probably introduced back in 1.0d24) which frequently prevented
the SIVC code in MacTCP Monitor from notifying the user when the product
went out of date. The queries were made correctly, but the responses
could be lost after being received and parsed. Oops. This bug also resulted
in clients making a number of unnecessary automatic queries to the SIVC
server. (Automatic queries from versions of MacTCP Monitor prior to 1.0d26
will no longer be counted in the User Base total, as a result.)
Anyway, tell your friends to upgrade to 1.0d26; they may not find out about
it otherwise. (Note that the "Current Version Info" item in the "Special"
menu has always worked fine, so regardless of what version people currently
have, they can still do the download of 1.0d26 that way.)
* Fixed a bug which resulted in a bad value for the next automatic SIVC query
time being recorded in the prefs file.
* MacTCP Monitor now checks for the presense of Color QuickDraw while it loads.
If it doesn't find it, the program *should* just quit now, instead of
crashing. I don't have a machine around here without Color QuickDraw, so I
can't test this, but the check is simple and should work as anticipated.
* Various minor adjustments in the application shell. None of these
adjustments should result in an apparent change of behavior in this product,
but were necessary to make other products work properly.
Changes in 1.0d25
-----------------
* Fixed a logic error which prevented the data transfer graph from being
updated when the graph labels were entirely obscured; used an "and" where
I should have used an "or". Nuts.
* Replaced the "Current Version Info" dialog with the slightly redesigned one
from the SIVC Client application which is currently in the works. The new
dialog is slightly more compact, while displaying all the same information.
* Fixed some anachronistic resource names. This had no effect on anything, it
just made me feel better. :-)
Changes in 1.0d24
-----------------
* Rewrote TCP Data Transfer Graph plotting code. Previous code was highly
optimized for the case in which only a reasonable number of samples were
being drawn at the right edge of an *unobscured* window. Judging from some
of the email I've received, that was the wrong case for which to optimize.
I had originally believed that the only alternatives I had were (a) an
implementation which would tend to flicker when drawing new samples
(blech!), or (b) an implementation using an off-screen pixmap which would
use memory like it was going out of style (especially for large windows
on deep monitors).
Instead, a variation of the aforementioned option 'a' has been implemented,
with a lot of work devoted to limiting flicker. From my own testing, it
seems to work fine, with only a little additional flicker (which may or may
not actually be noticeable) when processing update events. In exchange, it
plots much faster than its predecessors, especially when the graph window
is partially obscured.
* When the graph window is resized, its new position is now recorded in
the prefs file. In the past it appears that only the new window *size*
was stored, resulting in the window reappearing in an unexpected place
when the program was next launched.
* Clicking on one of the graph's resize edges/corners without actually
doing a resize no longer results in the window being redrawn and the
window's position being rewritten to the prefs file.
* DebugStr calls will now only be made on machines that actually have MacsBug
installed. :-) This should eliminate some "unimplemented trap" crashes
that one person reported. If you do have MacsBug, be prepared for the
unlikely possibility that you might see one of my debugging messages some
day. If you do, jot it down, type 'g' on your keyboard, and hit return. The
application will go back to running as normally as it can under whatever
weird circumstances it has encountered. If you see additional messages, just
repeat the aforementioned steps. Finally, send me a message telling me about
those messages and what was going on when they appeared. (Extreme low-memory
conditions are a possible cause, BTW.)
* Made further attempts to reproduce the bug that results in the Apple menu
being disabled on 68K Macs. No luck so far. However, I have removed some
redundant old code from the primary menu handling routine that just might
have been able to cause such a problem. If you were experiencing this
problem and find that it's fixed now, please let me know. By the same token,
if it isn't fixed, please let me know.
Changes in 1.0d23
-----------------
* Edit menu items are now enabled in any dialog that contains text edit
fields. For simplicity at this stage, the items are enabled whether or
not they happen to be useful at the time, e.g. the "Copy" item will be
enabled even if there's no text selected at the time. I'll take care
of such details later, after I rearrange the menu handling code.
* Fixed a typo in the About box. I'm so embarassed. But, hey, if you
didn't notice, I'm not gonna tell you what it was. :-)
Changes in 1.0d22
-----------------
* Fixed a bug in the URL opening code which prevented it from correctly
checking the versions of the applications to which it was considering
sending "Get URL" AppleEvents. Due to bugs in versions of some apps
which provide "Get URL" capabilities, this could cause crashes (none
were reported, though).
Changes in 1.0d21
-----------------
* Added alerts to notify users of basic failure conditions: Thread Manager
not present, AppleEvents not present, and that kind of really basic stuff.
In the past when these conditions were detected, the program would just
beep three times and quit.
* Added links to info about the product and me to the About dialog. Since
I'd already added the "mailto:" link to my email address in a previous
version, these additions just seemed to make sense. Had to considerably
beef up my URL opening code in the process.
* Replaced previous U.T. logo in the About dialog with a considerably
cleaner version.
* I had hoped to do some basic restructuring in a few areas, but things have
been busy lately and haven't, as a result, allowed much time for serious
work on this product. Hopefully things will improve in a couple of weeks.
Changes in 1.0d20
-----------------
* Corrected an error in the TCP Data Transfer Graph drawing logic which
resulted in at least one pixel of "writing" being plotted in the graph
during any second in which data was transferred, even if all the data
was actually being read at that time.
* Made the TCP Connection States window appear open by default. (It used to
be closed by default.)
Changes in 1.0d19
-----------------
* Acting on an old suggestion from Peter Lewis, made my email address in the
About box into a "mailto" URL link. Just click on it (it's blue and
underlined just as it would appear in most WWW clients) and it'll fire-up
NewsWatcher and create a blank email message addressed to me. In order for
this feature to work, you must have a current version of John Norstad's
NewsWatcher application (like 2.0b24).
* Revised my simple-minded URL-opening code to be slightly less simple-minded.
It now knows about "ftp", "mailto", "news", "http", and "gopher" URLs. (It
used to only deal with "ftp" URLs.)
Changes in 1.0d18
-----------------
* Changed TCP data transfer statistics gathering code to separately store
information on bytes read and written. (These totals used to be added
together and stored in a single field.)
* Changed TCP data transfer graph to draw separate read and write bars, one
stacked on top of the other. (The write bar is always on top.)
* Changed TCP data transfer graph preferences dialog to allow you to set the
colors of the aforementioned read and write bars. By default, the read and
write bars are set to dull shades of green and red, respectively.
* Changed some Preferences menu items and preference window titles to
be a little more specific about their purposes.
* Changed the "Contacting User Counter Server..." dialog to read "Contacting
SIVC Server...". The "User Counter" name has been a misnomer for a while.
Changes in 1.0d17
-----------------
* Added a "Connection State Cells" preferences dialog, and modified the
Connection States window to make use of the values set therein.
* When copying the Connection States window to the Clipboard, the image is
now framed. I think it looks better this way.
* If the prefs. file was open in another application with read/write access
and MacTCP Monitor was launched, it would startup, revert to its default
configuration, and attempt to close the unopened MacTCP resolver when the
user quit the program. This has been fixed. Now 'Monitor just beeps three
times and exits in this situation, which shouldn't arise in normal usage.
Changes in 1.0d16
-----------------
* Made the "New" item in the "File" menu hierarchical, and placed items in that
hierarchical menu for opening all the major features of MacTCP Monitor -
the data transfer graph, and the connection states window. The "Connection
States" item has been removed from the "Special" menu as a result.
* Added a "Connection State Colors" item to the preferences menu. The dialog
behind that item allows you to set separate colors for each and every
TCP connection state, as well as for the read and write indicators. Patterns
to go along with each color may also be designated, which is likely to
be useful on machines with limited color palettes.
* Corrected (in all probability) a bug that would occasionally prevent the
last active connection in the connection state window from being redrawn
in the closed state when it was closed.
* Fixed a bug in the launch-by-signature code that prevented MacTCP Monitor
from launching MacTCP Watcher and Anarchie if they were stored on anything
other than the startup volume.
Changes in 1.0d15
-----------------
* Based on a suggestion from Peter N. Lewis, added a window for monitoring
the state of all 64 of the connections MacTCP will support at any given
time. Connection states are color-coded as follows:
+ Gray -- Connection is closed. (Closed.)
+ Blue (50%) -- Listening for, or establishing, a connection. (Listen,
SYNReceived, and SYNSent.)
+ Blue (solid) -- Connection open. (Established.)
+ Cyan -- Connection closing (FINWait1, FINWait2, CloseWait,
Closing, and LastAck.)
+ Yellow -- Breaking connection. (TimeWait.)
In addition, green and/or red color bars may be overlaid to indicate that
data is being read and/or written, respectively, on the connection.
At present, you open this window by choosing the "Connection States" item
in the "Special" menu. I'll probably move it somewhere else in a future
version.
In the future, I'll add a preferences dialog that'll let you pick the colors
used for all these states, set the cell size in the window, etc.
* Fixed a bug in the Thread Message Manager's time distribution routine. The
bug shouldn't have effected previous versions, but became a problem when
the connection state window was added.
* Moved the "Windows" menu to the end of the menu bar. This seems like a
better place for it.
* Probably did some other stuff, too, but still haven't worked on Rick
Watson's useful suggestions.
Changes in 1.0d14
-----------------
* Incorporated John Nortsad's correction to the definition of the TCPSendPB
parameter block in the MacTCP.h header from Apple's version 2.0a3 of the
Universal Headers. (The "filler" field was in the wrong place in Apple's
version.)
* Retouched the U.T. System seal in the about box in order to make it look
the same in the 256, Thousands and Millions color modes. Previous versions
looked fine in the Thousands and Millions modes, but not in the 256 color
mode. (Hey, I always use Millions. :-)
Changes in 1.0d13
-----------------
* Fixed problem with radio buttons in 68K version.